Just to clarify the consequence i noticed when implementing my own xpbd physics engine.
According to coulomb friction model, two objects with different mass but same friction coefficients and initial velocity should come to rest at the same time/distance. But with the original equation, heavy objects will come to a stop much sooner than light objects.

Thanks, the friction definitely seems to be working in a more realistic way with bodies that have different masses now. However, this does seem to increase the amount of "explosions", especially with larger dynamic friction coefficients; below is the cubes example with a coefficient of 1.0.

This was already a problem to some extent, but not nearly as strong. I don't know what's causing it, but it probably isn't the friction in itself. One thing I've been wondering is if r1 and r2 are supposed to be the original contact positions in world space or the local contact positions rotated by the current rotations of the bodies, which would approximate the current contact positions in world space.

Also, is the 10 minute physics Discord server private? I have tried looking for it but couldn't find it. I was thinking that it might be useful for me to be on there since I maintain this physics engine.

Unsure if its allowed to post links here, but the discord channel should not be private. It can be found in from the youtube channel, then community tab.
Regarding r1 and r2, they should be the local offsets. So they can be transformed to correct world coordinates with updated poses of the rigid bodies.
Very interesting behavior with jumping boxes :P I haven't really used the library (I sometimes compare specific parts to my own implementation in C#) but if I have time I can look for some errors.

Hi again, the explosions were fixed by #90 for contacts between convex colliders (like the cubes), and this PR works fine now, as I'm no longer seeing any jumping cubes. For non-convex colliders like trimeshes there are still problems though, so I'll wait a little longer until I get this PR merged.

If you don't mind, I can also take over in terms of fixing merge conflicts and such. Just to be sure, I'll also compare with other engines to make sure the friction works correctly both in 2D and 3D.

Hi, great, i don't mind if you take over the merge conflicts.
I saw that you implemented contact manifold to solve the contact explosions. Which for me seems strange, in my implementation i only use single contact between bodies and have never encountered such issues.
I noticed that changes was made to use the local contact points but i assume the issue still remained, (before manifolds was implemented). But i suspect the issue from the beginning was that the penetration depth was not recalculated at each solve?

I quickly read the contact solve code and noticed some things that is not correct (or at least differs from my implementation)

1. The contact normal should also be defined in local coordinates for either body 1 or body 2, the normal should then be transformed to world at every solve just like the local contact points (to have the correct direction)
2. When calculating the static friction the corresponding normal and tangential λ should be used, not the correction magnitude (in this case penetration for the normal and relative contact point speed for the tangent)

Thanks, the normals should probably be stored as local and transformed to world space at every solve like you mentioned, and the static friction should also be fixed. I'll fix these later.

However, neither one of these is causing the actual explosiveness. Completely removing static friction doesn't help, and the contact normal fix doesn't seem to help either, although it might reduce drifting a bit.

I'm thinking that it could somehow be caused by floating point precision problems and numerical instability, because using f64 instead of f32 removes the explosiveness. According to logs, the Lagrange multiplier update is unusually big at explosions due to a value of c (the penetration) that is nearly 10 times as large as normal, so the problem is probably somewhere in the penetration constraint. Or maybe there is occasionally an inverted normal somehow that pulls the cube deeper into the ground, which causes a much larger penetration the next frame.

FYI the contact normal fix reduces drifting and makes cube stacking significantly more stable, see #97

Hi, I finally revisited this PR, resolved the conflicts and made some minor improvements to naming and comments.

I also compared this against Unity just to verify, and the results look quite good if not better than Unity:

The bigger boxes travel the same distance as the smaller ones, as expected. It does look like our friction might be slightly weaker than Unity's (both use coefficient of 0.3), but that could also be a setup problem or something.

I still haven't fixed all of the collision problems I mentioned earlier, but it's not worth delaying this PR more since it doesn't seem like it's causing any problems that aren't present on the main branch. I'm happy to finally get this merged tomorrow :)